The wide adoption of operating system (OS) containers has led to the rise of a class of applications referred to as cloud-native applications. These applications typically adopt a microservices architecture, where each application component is packaged as a microservice with its own API and typically runs as a separate instance, or “container.” Such containers typically wrap a piece of software in a complete file system that contains everything needed to run including, but not limited to code, runtime parameters, system tools, system libraries, etc.
Further, container orchestration technologies provide additional assistance in the deployment and execution of cloud-native applications on a cluster of hosts. While such containers have largely simplified the building, shipping, and execution of cloud-native applications, deployment and capacity planning in connection with such applications still require a significant amount of resources. Specifically, when an application operator needs to deploy a cloud-native application, several questions arise including, but not limited to: to which cloud provider and to which location to deploy the application, what scaling factor to use for each application component, what initial resource configuration to use for each container, etc.
It is nontrivial to determine suitable answers to these questions, especially for business critical applications with essential operational requirements regarding cost, availability, and performance. To date, the process of addressing the foregoing during application deployment can be highly labor-intensive, inaccurate, and/or error-prone.